ETSITS183 064V2.1.1 



(2008-10) 



Technical Specification 



Telecommunications and Internet converged Services and 

Protocols for Advanced Networking (TISPAN); 

Dedicated IPTV subsystem stage 3 specification 




ETSI TS 183 064 V2.1.1 (2008-10) 



Reference 



DTS/TISPAN-031 37-NGN-R2 
Keywords 



IP, TV, Stages 



ETSI 

650 Route des Lucioles 
F-06921 Sophia Antipolis Cedex - FRANCE 

Tel. : +33 4 92 94 42 00 Fax: +33 4 93 65 47 1 6 

Siret N ° 348 623 562 0001 7 - NAF 742 C 
Association a but non lucratif enregistree a la 
Sous-Prefecture de Grasse (06) N° 7803/88 



Important notice 



Individual copies of the present document can be downloaded from: 
http://www.etsi.orq 

The present document may be made available in more than one electronic version or in print. In any case of existing or 

perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). 

In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive 

within ETSI Secretariat. 

Users of the present document should be aware that the document may be subject to revision or change of status. 

Information on the current status of this and other ETSI documents is available at 

http://portal.etsi.orq/tb/status/status.asp 

If you find errors in the present document, please send your comment to one of the following services: 

http://portal.etsi.orq/chaircor/ETSI support.asp 

Copyright Notification 

No part may be reproduced except as authorized by written permission. 
The copyright and the foregoing restriction extend to reproduction in all media. 

© European Telecommunications Standards Institute 2008. 
All rights reserved. 

DECT™, PLUGTESTS™, UMTS™, TIPHON™, the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered 

for the benefit of its Members. 
3GPP™ is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. 



ETSI 



ETSI TS 183 064 V2.1.1 (2008-10) 



Contents 



Intellectual Property Rights 5 

Foreword 5 

1 Scope 6 

2 References 6 

2.1 Normative references 7 

2.2 Informative references 8 

3 Definitions and abbreviations 8 

3.1 Definitions 8 

3.2 Abbreviations 8 

4 Applicability 10 

4.1 Concept and Approach 10 

4.2 Overview 10 

4.3 Functional Entities 13 

4.3.1 User Equipment(UE) 13 

4.3.2 Service Discovery and Selection (SD&S) 13 

4.3.3 Customer Facing IPTV Applications (CF-IPTV-Apps) 13 

4.3.4 IPTV Control (IPTV-C) 13 

4.3.5 Media Control Function (MCF) 13 

4.3.6 Media Delivery Function (MDF) 13 

4.3.7 IPTV User Data Function (IPTV UDF) 13 

4.3.8 NGN User Data Access Function (NGN UDAF) 14 

5 Procedures using HTTP for dedicated IPTV 14 

5.1 User Equipment (UE) 14 

5.1.1 Procedures fbr SD&S 14 

5.1.1.1 Push mode 14 

5.1.1.2 Pull Mode 14 

5.1.2 Procedure for Service Configuration 14 

5.1.3 Procedure for Authentication 15 

5.1.4 Procedure for Customer Facing IPTV Applications 15 

5.1.5 Procedure for Notifications 15 

5.1.6 Procedure for Messaging 15 

5.1.7 Procedure for presence information 15 

6 Procedures using RTSP for dedicated IPTV 15 

6.1 User Equipment (UE) and Control Functions 17 

6.1.1 Procedure for BTV service 17 

6.1.2 Procedure for CoD service 17 

6.1.3 Procedure for BTV with trick modes service 19 

6.1.4 Procedure for time-shift TV 19 

6.1.5 Procedure fbr nPVR 20 

6.2 IPTV Control (IPTV-C) 20 

6.2.1 Procedure for BTV service 20 

6.2.2 Procedure for CoD service 20 

7 Procedures using IGMP for dedicated -IPTV 20 

7.1 User Equipment (UE) 20 

7.1.1 Procedure for BTV service 21 

7.1.1.1 Procedure for starting to receive multicast 21 

7.1.1.2 Procedure for stopping to receive multicast 21 

7.1.1.3 Procedure for channel switching 21 

7.1.2 Procedure for BTV with trick modes service 21 

7.2 Transport Functions 22 

8 Procedures using SIP for dedicated -IPTV 22 



£75/ 



4 ETSI TS 1 83 064 V2.1 .1 (2008-1 0) 

8.1 User Equipment (UE) 22 

8.1.1 Procedure for Notifications 22 

8.1.2 Procedure for Messaging 22 

9 Procedures using DVBSTP for dedicated-IPTV 22 

9.1 User Equipment (UE) 22 

9.1.1 Service Discovery and Selection (SD&S) 22 

9.1.1.1 Request of DVB Service Discovery and Selection data 22 

9.1.1.2 Request of DVB Broadband Content Guide 23 

9.2 Service Discovery and Selection (SD&S) 23 

9.2.1 Procedure for Service Selection 23 

9.2.1.1 Delivery of DVB Service Discovery and Selection data 23 

9.2.1.2 Delivery of DVB Broadband Content Guide 23 

10 Procedures using RTP/RTCP and UDP for dedicated IPTV 23 

10.1 User Equipment (UE) 23 

10.1.1 Procedures for Real-Time Transport 23 

10.1.1.1 Transport using MPEG2TS 23 

10.1.2 Procedure for Real-Time Transport Error Correction 23 

10.1.2.1 Unidirectional Transport Error Correction 23 

10.2 Media Delivery Function (MDF) 24 

10.2.1 Procedures for Real-Time Transport 24 

10.2.1.1 Transport using MPEG2TS 24 

10.2.2 Procedure for Real-Time Transport Error Correction 24 

10.2.2.1 Unidirectional Transport Error Correction 24 

Annex A (informative): Functional entity relations and example signalling flows of NGN 

based dedicated IPTV operations 25 

A . 1 Functional entities relations and overview of the NGN based dedicated IPTV procedures 25 

A.2 Example signalling flows of service discovery and selection 26 

A. 3 Signalling flow and protocol RTP/RTCP for Retransmission 27 

A. 3.1 User Equipment (UE) procedure for BTV service 27 

A. 3. 2 User Equipment (UE) procedure for CoD service 28 

A.4 Example signalling flows of nPVR 29 

A. 5 Example signalling flows of IPTV service for messaging 30 

A. 6 Example signalling flows of IPTV presence services 32 

A.6.1 Example signalling flows of IPTV presence notification using PA 32 

A.6.2 Example signalling flows of IPTV presence notification using RLS 34 

A.6.3 Example signalling flows of IPTV presence updates 35 

A.7 Example signalling flows of IPTV service interaction with NGN/IMS services 35 

A. 7.1 Example signalling flows of IPTV service handling of incoming calls 36 

A. 8 Example signalling flows of Notifications 38 

Annex B (normative): UE capabilities and example signalling flows of NGN based dedicated 

IPTV operations 40 

B.l UE capabilities 40 

B.2 Signalling flows of BTV 41 

B.3 Signalling flows of CoD 43 

B.3.1 CoD Session initiation 43 

B.3.2 CoD Session termination 44 

B.4 Signalling flows of BTV with trick modes 44 

History 46 



£75/ 



ETSI TS 183 064 V2.1.1 (2008-10) 



Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Telecommunications and Internet 
converged Services and Protocols for Advanced Networking (TISPAN). 



ETSI 



ETSI TS 183 064 V2.1.1 (2008-10) 



Scope 



The present document provides the stage 3 description of the dedicated IPTV subsystem based on the architecture and 
stage 2 information flows described in TS 182 028 [4]. 

The protocol enhancements will form the scope of new or enhanced protocol specifications. 

The interaction with other NGN subsystems such as PES, IMS and RACS will be considered. 

The current release is applicable to: 

• the interface between the User Equipment (UE) and the SD&S; 

• the interface between the User Equipment (UE) and Customer facing IPTV Applications (CF-IPTV-Apps); 

• the interface between the User Equipment (UE) and IPTV Control (IPTV-C); 

• the interface between the User Equipment (UE) and Media Control Functions (MCF); 

• the interface between the User Equipment (UE) and Media Delivery Functions (MDF); 

• the interface between the Customer facing IPTV Applications (CF-IPTV-Apps) and IPTV Control (IPTV-C); 

• the interface for access to IPTV User Data Function (IPTV UDF); 

• the interface between the IPTV Control (IPTV-C) and Media Control Functions (MCF); 

• the interface for access to NGN User Data Access Function (NGN UDAF). 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 

cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

For online referenced documents, information sufficient to identify and locate the source shall be provided. Preferably, 
the primary source of the referenced document should be cited, in order to ensure traceability. Furthermore, the 
reference should, as far as possible, remain valid for the expected life of the document. The reference shall include the 
method of access to the referenced document and the full network address, with the same punctuation and use of upper 
case and lower case letters. 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 
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2.1 Normative references 



The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[I] ETSI ES 282 001 (Release 2): "Telecommunications and Internet converged Services and 
Protocols for Advanced Networking (TISPAN); NGN Functional Architecture". 

[2] ETSI ES 282 004 (Release 2): "Telecommunications and Internet converged Services and 

Protocols for Advanced Networking (TISPAN); NGN Functional Architecture; Network 
Attachment Sub-System (NASS)". 

[3] ETSI ES 282 003 (Release 2): "Telecommunications and Internet converged Services and 

Protocols for Advanced Networking (TISPAN); Resource and Admission Control 
Sub-System (RACS): Functional Architecture". 

[4] ETSI TS 182 028 (Release 2): "Telecommunications and Internet converged Services and 

Protocols for Advanced Networking (TISPAN); IPTV Architecture; Dedicated subsystem for 
IPTV functions". 

[5] ETSI TS 102 034: "Digital Video Broadcasting (DVB); Transport of MPEG-2 TS Based DVB 

Services over IP Based Networks". 

[6] IETF RFC 2326 (April 1998): "Real Time Streaming Protocol (RTSP)". 

[7] IETF RFC 2617 (June 1996): " HTTP Authentication: Basic and Digest Access Authentication". 

[8] ETSI TS 102 539: "Digital Video Broadcasting (DVB); Carriage of Broadband Content 

Guide (BCG) information over Internet Protocol (IP)". 

[9] IETF RFC 2616 (June 1999): "Hypertext Transfer Protocol - HTTP/1.1". 

[10] IETF RFC 3428 (December 2002): "Session Initiation Protocol (SIP) Extension for Instant 

Messaging". 

[II] ETSI TS 183 041 (Release 2): "Telecommunications and Internet converged Services and 
Protocols for Advanced Networking (TISPAN); Messaging service using the IP Multimedia (IM) 
Core Network (CN) subsystem; Stage 3: Protocol specifications [Endorsement of 

3GPP TS 24.247 Release 6]". 

[12] IETF RFC 3856 (August 2004): "Presence Event Package for the Session Initiation 

Protocol (SIP)". 

[13] ETSI TS 182 008 (Release 2): "Telecommunications and Internet converged Services and 

Protocols for Advanced Networking (TISPAN); Presence Service; Architecture and functional 
description [Endorsement of 3GPP TS 23.508 Release 7 and OMA-AD-Presence_SIMPLE- 
V1_0]". 

[14] IETF RFC 4662 (August 2006): "Session Initiation Protocol (SIP) Event Notification Extension 

for Resource Lists". 

[15] IETF RFC 4825 (May 2007): "The Extensible Markup Language (XML). Configuration Access 

Protocol (XCAP)". 

[16] IETF RFC 5025 (December 2007): "Presence Authorization Rules". 

[17] ETSI TS 183 063 (Release 2): "Telecommunications and Internet converged Services and 

Protocols for Advanced Networking (TISPAN); IMS-based IPTV stage 3 specification". 

[18] IETF RFC 3265 (June 2002): "Session Initiation Protocol (SlP)-Specific Event Notification". 

[19] IETF RFC 1321 (April, 1992): "The MD5 Message-Digest Algorithm". 

[20] IETF RFC 3376 (October 2002): "Internet Group Management Protocol, Version 3". 
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[21] IETF RFC 3810 (June 2004): "Multicast Listener Discovery Version 2 (MLDv2) for IPv6". 

[22] ETSI TS 183 017 (Release 2): "Telecommunications and Internet Converged Services and 

Protocols for Advanced Networking (TISPAN); Resource and Admission Control: DIAMETER 
protocol for session based policy set-up information exchange between the Application 
Function (AF) and the Service Policy Decision Function (SPDF); Protocol specification". 

[23] IETF RFC 4585 (July 2006): "Extended RTP Profile for Real-time Transport Control 

Protocol (RTCP)-Based Feedback (RTP/AVPF)". 

[24] IETF RFC 4588 (July 2006): "RTP Retransmission Payload Format" . 

[25] IETF RFC 3261: "SIP: Session Initiation Protocol". 

[26] ETSI TS 184 009 (Release 2): "Telecommunications and Internet converged Services and 

Protocols for Advanced Networking (TISPAN) Rules covering the use of TV URIs for the 
Identification of Television Channels". 

2.2 Informative references 

The following referenced documents are not essential to the use of the present document but they assist the user with 
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including 
any amendments) applies. 

[i.l] ETSI TS 187 003 (Release 2): "Telecommunications and Internet converged Services and 

Protocols for Advanced Networking (TISPAN); NGN Security; Security Architecture". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

UE (converged): end user device, eg set top box or enhanced TV, capable of supporting IPTV services and services 
provided by other NGN subsystems 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

ASF Application Server Function 

BC Broadcast 

BCG Broadband Content Guide 

BTV Broadcast TV 

CF Customer Facing 

CFIA Customer Facing IPTV Applications 

CoD Content on Demand 

CoD-MF Content on Demand Media Functions 

CSS Cascading Style Sheets 

Ct2 interfaces name defined in TS 182 028 [4] 

Di interfaces name defined in TS 182 028 [4] 

DVB Digital Video Broadcast 

DVBSTP Digital Video Broadcasting Service discovery and selection Transport Protocol 

ECF Elementary Control Function 

EFF Elementary Forwarding Function 

EPG Electric Program Guide 

FB FeedBack 

FE Functional Entity 

HTTP HyperText Transfer Protocol 
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IGMP Internet Group Management Protocol 

IGMPv2 Internet Group Management Protocol version 2 

IGMPv3 Internet Group Management Protocol version 3 

IMS IP Multimedia Subsystem 

IPTV Internet Protocol Television 

IPTV-C IPTV Control 

IPv4 Internet Protocol version 4 

lUDF IPTV User Data Function 

LMB Linear Media Broadcast 

MBwTM Media Broadcast with Trick Modes 

MC MulitCast 

MCF Media Control Function 

MDF Media Delivery Function 

MLD Multicast Listener Discovery (protocol) 

MLDvl Multicast Listener Discovery version 1 

MLDv2 Multicast Listener Discovery version 2 

NGN Next Generation Network 

nPVR network-side Personal Video Recorder 

PS Presence Server 

PUA Presence User Agent 

RACS Resources Admission Control Sub-system 

RLS Resource List Server 

RR Receiver Report 

RSI Receiver Summary Information 

RTCP Real Time Control Protocol 

RTCPSSM RTCP extension for Source Specific Multicast 

RTP Real Time transport Protocol 

RTSP Real Time Streaming Protocol 

Sa interfaces name defined in TS 182 028 [4] 

SD&S Service Discovery and Selection 

SDES Source Description RTCP Packet 

SDP Session Initiation Protocol 

Sh interfaces name defined in TS 182 028 [4] 

SIP Session Initiation Protocol 

SMTP Simple Mail Transfer Protocol 

SSRC Synchronization SouRCe 

TCP Transmission Control Protocol 

Tr interfaces name defined in TS 182 028 [4] 

TsTV Time-shift TV 

Ud interfaces name defined in TS 182 028 [4] 

UDP User Datagram Protocol 

UE User Equipment 

UPSF User Profile Server Function 

URI Uniform Resource Identifier 

URL Uniform Resource Locator 

WEB4CE Web-based Protocol and Framework for Consumer Electronics 

Xc interfaces name defined in TS 182 028 [4] 

XCAP XML Configuration Access Protocol 

Xd interfaces name defined in TS 182 028 [4] 

XDMS XML Data Management Server 

XML Extensible Markup Language 
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4 Applicability 

The following clauses explain the concept and approach used to define the protocols for the dedicated IPTV subsystem. 



4.1 Concept and Approach 



This clause outlines concept and approach adopted in the present document. The approach is then applied to protocol 
selections, mapping to interfaces and protocol extensions. 

The document focuses on defining protocols for flexible functional architecture described in [4], which can: 

• Allow development of new IPTV subsystem in NGN; 

• Integrate existing IPTV subsystem in NGN; 

• Extend both to support other NGN services. 

In order to achieve high level of flexibility and support integration of existing subsystems, the work is focused on 
evaluating and endorsing protocols already defined for similar functions in [5] and other standard bodies. Protocol 
extensions are defined where applicable as well as overall applicability to the end-to-end architecture [4]. 

For example, recommendations are made how to integrate DVB compliant UE without modifications and DVB 
compliant system with minimal modification to the service layer. 

4.2 Overview 

The clause describes applicability of the protocols discussed further in the present document to reference points defined 
in TS 182 028 [4]. The overall functional architecture for the dedicated IPTV service conforms to [4]. 

Figure 1 presents mapping of protocols to interfaces in dedicated NGN-IPTV and to interworking with other NGN 
subsystems and common components. 
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Legend: NGN dedicated IPTV model 



UDP/RTP/RTCP 

Diameter 

RTSP 

HTTP 

IGMP/MLD 

DVBSTP 



Other 

Not defined 



NOTE: Xc and Xd are logical interfaces that can be decomposed into Dj and optionally Di, Ds or Iz interfaces 

depending on the location of the MCF or MDF as described in [4] clause 5.2.5 for Xc and clause 5.1 .6 for 
Xd. 

Figure 1 : Protocols mapped to NGN dedicated IPTV functional architecture 
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Table 1 : NGN dedicated IPTV functional entities and protocols used on interfaces 
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NOTE 1 : NGN dedicated IPTV protocol model is required to comply with standards applicable for NGN dedicated 
IPTV as defined below. 

Usage of the HTTP protocol across the following interfaces is described in clause 5: 

• interface Tr; 

• interface Xc; 

• interface Ct2 (Optional). 

Usage of the HTTP protocol for interactions between NGN Applications and UE is described in annex E. 
Usage of the RTSP protocol across the following interfaces is described in clause 6: 

• interface Ct2; 

• interface Xc. 

Usage of the IGMP/MLD protocol across the following interfaces is described in clause 7: 

• interface Dj, Di. 

Usage of the SIP protocol for interactions between NGN Applications and UE is described in the clause 8. 
Usage of the DVBSTP across the following interfaces is described in clause 9: 

• interface Tr. 

Usage of the RTP/RTCP protocol across the following interface is described in clause 10: 

• interface Xd. 
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Usage of the MPEG2 TS across the following interfaces is described in clause 10: 

• interface Xd; 

• interface Tr. 

NOTE 2: Applications can be transferred as private data streams inside MPEG2 TS. Applicability of MPEG2 TS to 
Tr interface is outside the current release. 

Usage of the AL-FEC protocol across the following interface is described in clause 10: 

• interface Xd. 

Use of Diameter shall comply to the following specifications: 

• [22] and [3] for interface; 

• [3] for e2 interface; 

• [ 1 ] for S h interfaces . 

4.3 Functional Entities 

The functional entities that constitute the NGN dedicated IPTV subsystem are defined in TS 182 028 [4]. The following 
clauses summarize the functionality of each functional entity. 

4.3.1 User Equipment(UE) 

The UE is a functional entity that provides the user with access to IPTV services. 

4.3.2 Service Discovery and Selection (SD&S) 

The Service Discovery and Selection (SD&S) is a functional entity that provides description information for discovery 
of the service as well as information required for description and selection of IPTV services. 

4.3.3 Customer Facing IPTV Applications (CF-IPTV-Apps) 

The Customer Facing IPTV Application (CFIA) is a functional entity that provides IPTV service provisioning, selection 
and authorization. 

4.3.4 IPTV Control (IPTV-C) 

The IPTV Control (IPTV-C) is a functional entity that checks if UE has been authorized by the Customer Facing IPTV 
Application to use IPTV Service Control and Delivery Functions (provides selection of the Media Control Function). 

4.3.5 Media Control Function (MCF) 

The Media Control Function (MCF) is a functional entity that provides the UE with functions required to control media 
flows and manages the MDFs under its control. 

4.3.6 Media Delivery Function (MDF) 

The Media Delivery Function (MDF) is a functional entity that delivers content data to the UE. 

4.3.7 IPTV User Data Function (IPTV UDF) 

IPTV user data (lUDF) functional entity is responsible for handling dedicated IPTV user data. 
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4.3.8 NGN User Data Access Function (NGN UDAF) 

NGN Application User Data FE (NGN UDF) is a functional entity responsible for handling NGN application and user 
data. 



5 Procedures using HTTP for dedicated IPTV 

5.1 User Equipment (UE) 

5.1.1 Procedures for SD&S 

Mechanisms used to identify service providers and services in the context of service discovery shall apply conforming 
to TS 102 034 [5], clause 5.2. 

5.1.1.1 Push mode 

Push model delivery of BCGs using multicast shall use the DVBSTP protocol for this purpose in alignment with 
clause .4.1.2 of TS 102 034 [5]. 

5.1.1.2 Pull Mode 

In the pull model of unicast delivery of a DVB SD&S data, the HTTP protocol shall be used conforming to 
TS 102 034 [5], clause 5.4.2. 

In the pull model of unicast container-based delivery of DVB BCG data, the HTTP protocol shall be used conforming 
to TS 102 539 [8], clause 4.1.2.2.2. 

In the pull model of unicast query mechanism of DVB BCG data, the HTTP protocol is used to transport SOAP 
messages. This shall be conforming to TS 102 539 [8], clause 4.2. 

NOTE: Some services such as network PVR, notification may fall outside current [5] SD&S scope. In this case 
and for additional services the following mechanism may be used: 

■ The http request may contain other header fields conforming to the [9] and XML records specifying 
additional service name in the XML format; 

■ The response to the HTTP requests above shall contain matching XML service definition records 
or http URL of other SD&S server where this information can be discovered via alternative means. 

The additional XML definitions may be discarded by the UE. 

5.1 .2 Procedure for Service Configuration 

One of the following options should be supported. 

• An Application Server may implement the role of an XCAP server as described in [15] with standard 
authentication mechanisms as discussed below. 

• Standalone XDMS server may be used, in which case Tr interface is re-used between UE and the server. 
XCAP usage shall comply with [15]. 

• Service can be configured over standard http [9]. In this case UE normally implements WEB browser with 
JavaScript (v tbd) or higher support for running WEB applications. 
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5.1.3 Procedure for Authentication 

HTTP Digest [7] is recommended on the Tr interface. 

MD5 is recommended digest algorithm as defined in [19], MD5 Message Digest Algorithm. 

5.1 .4 Procedure for Customer Facing IPTV Applications 

Application interface is based on http protocol between UE (converged) and ASF (Customer Facing IPTV applications). 

UE should implement an http [9] compliant web browser with JavaScript support. Special requirement for CSS is to 
support to enable rendering capabilities. 

A particular implementation of the Web Browser is outside the scope of the present document, however, most of widely 
used browsers can be supported. 

Application Gateway may be used on the Tr interface; however, the gateway specification is outside the scope of the 
prestent document. 

5.1 .5 Procedure for Notifications 

The UE may receive notifications from the CFIA using Tr interface between the UE (converged) and IPTV ASF 
(Customer Facing IPTV applications) via HTTP protocol [9]. 



5.1.6 Procedure for Messaging 



The UE may initiate and present received messages via CFIA using Tr interface between UE (converged) and ASF 
(Customer Facing IPTV applications) via HTTP protocol [9]. 

The UE may initiate and present received messages through interactions with the Common NGN ASF as described in 
TS 182 028 [4], clause A. 

5.1 .7 Procedure for presence information 

The UE may receive presence information via CFIA on Tr interface via HTTP protocol [9]. 

The CFIA may use the Presence User Agent (PUA) as described in [12] and [13]. 

Alternatively, presence Network Agent as described in [13] may be used for IPTV in the Common NGN ASF as a 
gateway to the NGN Presence Server (PS). The Presence Server or agent can be located in the network. 

The PUA can request resource lists from a Resource List Server (RLS) as described in [14] to retrieve presence 
information from multiple users. 

The PUA (or presence network agent if used alternatively) should provide the mapping of IPTV user account to IMS 
user identities. 

UE may inform CFIA about presence status information. 

Alternatively presence information may be collected by the PUA or network agent (in Common NGN ASF) and 
reported to the NGN presence server. 



6 Procedures using RTSP for dedicated IPTV 

The Real Time Streaming Protocol [6], or RTSP, is an application-level protocol for control over the delivery of data 
with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of 
real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. 

This clause defines usage of RTSP in dedicated NGN IPTV for interactive control between UE and IPTV service 
control functions: IPTV-C and MCF. 
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RTSP application for interactive service control over IP multimedia delivery is defined in DVB-IPI [5] and unless stated 
explicitly otherwise, the application defined in DVB-IPI [5] is used. 

Service selection 

The service discovery and selection process as defined in clause 5 provides UE with the RTSP URL for initializing 
interactive multimedia delivery session. The URL discovery methods are discussed in clause 6.1.1 of [5]. 

The format of RTSP URL shall comply with [7]. 

Session transport 

A transient TCP connection is a temporary connection that exists only long enough to transmit one or more requests. 

The UE should use transient connection for exchanging control messages on Ct2 interface for selecting most suitable 
MCF function. After MCE is selected there is no need to keep the connection. 

A persistent TCP connection is a lasting connection between a client and RTSP server, all requests and replies are sent 
over the same connection, and the connection remains intact until the session is completed. The UE should use 
persistent connection for RTSP control over interactive media delivery on Xc interface. The usage of persistent 
connection is discussed in clause 6.1.2 of [5]. 

Optionally, transient connection can be used on Xc interface. 

A method to keep a persistent connection active is discussed in clause 6.1. 

Security considerations 

Security considerations discussed in clause 6.1.4 of [5] apply. 

Optionally HTTP Digest Access Authentication can be applied to RTSP control messages as defined in [7]. 

Mapping between DVB and TISPAN profiles 

The services defined in the service level requirements and dedicated IPTV architecture is identical when mapped to 
DVB service profiles as defined in table 2. 

Table 2: Mapping between TISPAN IPTV services and DVB service profiles 



TISPAN Service 


DVB Service profile 


BTV 


LMB 


BTV with trick modes 


MBwTM 


CoD 


CoD 


Time-shift TV 


CoD 


Networl< PVR 


CoD 



RTSP Methods 

RTSP methods supported for each profiles and their definitions are identical to clause 6.3 [5]. 

The requirement to support XML structures in clause 6.3 of [5] is optional. SDP parameters can be used instead. 

RTSP Headers 

The pause trick mode operation may be signalled by the standard RTSP PAUSE message as defined in [6]. 

RTSP scale header with value is optional. 
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6.1 User Equipment (UE) and Control Functions 

6.1 .1 Procedure for BTV service 

Usage of RTSP protocol for normal broadcast services without trick modes is not defined in the present document. 

6.1 .2 Procedure for CoD service 

NGN dedicated IPTV uses RTSP protocol [6] for control over the delivery of multimedia with real-time properties. 
Usage should be compliant with TS 102 034 [5] unless specified otherwise. 
Table 3 illustrates RTSP methods in [6], [5] and NGN dedicated IPTV. 

Table 3: RTSP methods in [6], [5] and NGN dedicated IPTV 



RTSP Method 


Direction: 
C = client - 

UE; 

S = Server - 

IVICF; 


RFC 2326 [6] 


DVB Requirement 
TS 102 034 [5] 


TISPAN 
NGN dedicated IPTV 








LMB 


MBwTM 
and CoD 


Coupled 
mode 


Decoupled 
mode 


ANNOUNCE 


C^S 


MAY 


MAY 


MAY 


MAY 


MAY 


ANNOUNCE 


S^C 


MAY 


SHOULD 


SHOULD 


SHOULD 


SHOULD 


DESCRIBE 


c^s 


SHOULD 


SHOULD 


SHOULD 


SHOULD 


SHOULD 


GET_PARAMETER 


c^s 


MAY 


SHOULD 


SHOULD 


SHOULD 


SHOULD 


GET_PARAMETER 


s^c 


MAY 


MAY 


MAY 


MAY 


MAY 


OPTIONS 


c^s 


SHALL 


SHALL 


SHALL 


SHOULD 


SHOULD 


OPTIONS 


s^c 


MAY 


MAY 


MAY 


MAY 


MAY 


PAUSE 


c^s 


SHOULD 


N.A. 


SHALL 


SHALL 


SHALL 


PLAY 


c^s 


SHALL 


SHALL 


SHALL 


SHALL 


SHALL 


REDIRECT 


s^c 


MAY 


SHALL 


SHALL 


N.A. 


SHALL 


SETUP 


c^s 


SHALL 


SHALL 


SHALL 


SHALL 


SHALL 


TEARDOWN 


c^s 


SHALL 


SHALL 


SHALL 


SHALL 


SHALL 


SET PARAMETER 


c^s 


MAY 


N.A. 


N.A. 


N.A. 


N.A. 


SET PARAMETER 


s^c 


MAY 


N.A. 


N.A. 


N.A. 


N.A. 


RECORD 


c^s 


MAY 


N.A. 


N.A. 


N.A. 


N.A. 


NOTE 1 : N.A. - Not Applicable. The text in bold shows optional difference in the required support of 

RTSP methods in NGN dedicated IPTV and TS 102 034 [5]. 
NOTE 2: ANNOUNCE, DESCRIBE, OPTIONS are optional methods which are not shown explicitly on 

the NGN dedicated IPTV flows, but may be supported by UE and MCF. 



Coupled mode: In the coupled mode Customer facing IPTV applications reserves the delivery resources via IPTV 
Control on Ss interface and returns the UE RTSP URL with the exact location of the MCF to request interactive media 
delivery. The format of RTSP URL shall comply with [6]. 
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The UE in the coupled mode shall send RTSP SETUP message containing at minimum RTSP URL, Sequence, and 
Transport headers to establish video delivery. Sample message flow in the coupled mode is shown in table 4. 

Table 4: Sample RTSP message flow in coupled mode 



RTSP Method 
from UE 


RTSP Method 
toUE 


Reference 
point 


Notes 


SETUP 




Xc 


UE requested on-demand session from MCF 




RTSP 200 OK 


Xc 




PLAY 




Xc 


UE requested the play-out to start 




RTSP 200 OK 


Xc 




GET PARAMETER 




Xc 


UE sends heartbeat to keep the session active 




RTSP 200 OK 


Xc 




PAUSE 




Xc 


UE initiated tricl< mode 




RTSP 200 OK 


Xc 






ANNOUNCE 


Xc 


IVICF made asynchronously announcement to the UE, 
e.g. "End of stream reached" 


RTSP 200 OK 




Xc 




TEARDOWN 




Xc 


UE closed on-demand session 




RTSP 200 OK 


Xc 





Decoupled mode: In the decoupled mode Customer facing IPTV applications return the UE RTSP URL with the exact 
location of the IPTV control. Resource reservation, selection of the exact MCF and session recovery is done via IPTV 
control at the time when the delivery is requested. 

The UE in the decoupled mode shall send RTSP SETUP message containing at minimum RTSP URL, Sequence, and 
Transport headers to establish video delivery. Sample message flow in the decoupled mode is shown in table 5. 

Table 5: Sample RTSP message flow in decoupled mode 



RTSP method 
from UE 


RTSP method 
toUE 


Reference 
point 


Notes 


SETUP 




Ct2 


UE requested on-demand session from IPTV control 




REDIRECT 


Ct2 


IPTV Control nominates MCF and reserves delivery 
resources 


SETUP 




Xc 


UE requested on-demand session from MCF 




RTSP 200 OK 


Xc 




PLAY 




Xc 


UE requested the play-out to start 




RTSP 200 OK 


Xc 




GET PARAMETER 




Xc 


UE sends heartbeat to keep the session active 




RTSP 200 OK 


Xc 




PAUSE 




Xc 


UE initiated trick mode 




RTSP 200 OK 


Xc 






ANNOUNCE 


Xc 


MCF made asynchronously announcement to the UE, 
e.g. "End of stream reached" 


RTSP 200 OK 




Xc 




TEARDOWN 




Xc 


UE closed on-demand session 




RTSP 200 OK 


Xc 





Decoupled mode can be used for on-demand session recovery in the real-time, e.g. due to MCF failure. The UE upon 
detection loss of stream repeats session initiation sequence from table 3, supplying the last position of the received 
video in the "Range" header of the first PLAY method. The newly allocated MDF continues media delivery from the 
interrupted position instead of the beginning. If the UE contains sufficient buffering, multimedia session is recovered 
without visible artefacts. 

Using both transient and persistent connection the UE should keep the session active by sending heartbeats in the form 
of RTSP GET_PARAMETER method at the negotiated time inter RTSP. This method is applicable to any control 
session during CoD, BTW with trick modes, time-shift TV and nPVR. 
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6.1 .3 Procedure for BTV with trick modes service 

Dedicated NGN IPTV media broadcast with trick modes session is a service level aggregation of broadcast and 
on-demand sessions. Combined session flow is shown in clause 11.3 of [4]. 

Before starting the service, the UE shall request from the Customer facing IPTV applications RTSP URL from where 
the interactive media delivery can be requested using RTSP protocol. 

The service is started by joining broadcast channel as specified in clause 7. The UE can pause the stream by leaving the 
broadcast stream as discussed and clause 7 and optionally setup interactive media delivery using identical procedure to 
the COD service, clause 6.1.2. 

Both coupled and decoupled modes can be supported. 

In the coupled mode Customer Facing IPTV application nominates a particular MCE for on-demand media delivery. 

In the decoupled mode the selection is performed in the real-time during switch to the trick mode. 

Sample message flow for BTV with trick modes in the decoupled mode is shown in table 6. 

Table 6: Sample message flow for BTV with trick modes in the decoupled mode 



from UE 


toUE 


Reference 
point 


Notes 


IGMPJOIN 




Xd (Dj, Dl or Ds) 


UE requested to join broadcast channel. 
The Access and Core network performs local 
admission control. Multicast channel is delivered 


IGMP LEAVE 




Xd (Dj, Dl or Ds) 


UE requested trick mode. UE leaves multicast 
channel 


RTSP SETUP 




Ct2 


UE requested on-demand session from IPTV 
control 




RTSP 
REDIRECT 


Ct2 


IPTV Control nominates MCF and optionally 
reserves delivery resources (previously reserved 
resources can be re-used) 


RTSP PLAY 




Xc 


UE requested the play-out to start 


TRICK MODE control on Xc 


TEAR DOWN 




Xc 


UE switches from trick mode 




RTSP 200 OK 


Xc 






ANNOUNCE 


Xc 


MCF made asynchronously announcement to the 
UE, e.g. "End of stream reached" 


RTSP 200 OK 




Xc 




IGMPJOIN 




Xd (Dj, Dl or Ds) 


UE switches back to life stream. 
The Access and Core network optionally performs 
local admission control, (previously reserved 
resources can be re-used) 



6.1.4 Procedure for time-slnift TV 

In order to provide time-shift TV service, MDF records TV programs available on the broadcast channels. The 
programs form a part of EPG (BCG) as discussed in clause 5 and should be requested on Tr interface. 

After selecting time-shifted content from EPG/BCG, the UE requests from the customer facing IPTV applications 
RTSP URL for initializing multimedia delivery time-shifted content. The procedure from this point is identical to CoD 
service defined in clause 6.1.2. 
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6.1 .5 Procedure for nPVR 

In order to provide nPVR service, the UE initially selected from EPG/BCG via customer facing IPTV application what 
content should be recorded in the MDF as discussed in clause 5. 

When the recording has been initiated, UE can request from the customer facing IPTV applications with the available 
recordings. The application of RTSP protocol for content delivery is identical to CoD procedure. 

NOTE: Both coupled and decoupled modes are supported for nPVR. 

In the coupled mode, client is allocated precise disk quote on a selected MDF. The MCF associated with the MDF is 
always selected for interactive control over nPVR services. 

In decoupled mode, statistical optimizations are possible, e.g. only one or small number of content copies is created and 
users are redetected to the nearest copies via Ct2 interface using RTSP REDIRECT. 

Content delivery's procedure is identical to time-shift TV service, MDF records TV programs available on the broadcast 
channels. The programs form a part of EPG (BCG) as discussed in clause 5 and should be requested on Tr interface. 



6.2 IPTV Control (IPTV-C) 



6.2.1 Procedure for BTV service 

Usage of RTSP protocol for normal broadcast services without trick modes is not defined in the present document. 

6.2.2 Procedure for CoD service 

IPTV Control upon receiving SETUP message from the UE on Ct2 interface, responds with the RTSP REDIRECT 
message containing at minimum sequence and location header. 

The location of the nominated MCF is passed in the location header. The header should comply with [6]: 

"Location: rtsp://host:port" 

"host = <A legal Internet host domain name of IP address (in dotted decimal form), as defined by clause 3.2 [6] >" 

"port = *DIGIT" 

7 Procedures using IGMP for dedicated -IPTV 

During SD&S process the UE shall discover multicast address to access broadcast IPTV services, e.g. BTV, BTV with 
trick mode. 

Broadcast IPTV services are based upon using multicast delivery and signalling as defined in the Internet Group 
Management Protocol [20]. The IGMP is applicable on the Xd interface. 

Xd interface can be subdivided into Dj, Di and Ds [4]. UE should use IGMP on the Dj interface. If the multicast stream 
is not available at the access network, the access network will propagate IGMP messages on the Di interface. 

7.1 User Equipment (UE) 

If IPv4 is used for the transport, the UE shall support IGMP v3 as described in [20] . 

If IPv6 is used for the transport, the UE shall support MLDv2 as described in [21]. 

Backward compatibihty rules between the UE and the Transport Function have to be done conforming [20] clause 7 and 
[21] clause 8. 
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7.1.1 Procedure for BTV service 

The IGMP protocol shall be used conforming to [5], clause 7.3.1 for: 

• initiating the BTV service on the discovered multicast address; 

• leaving the BTV service. 

7.1 .1 .1 Procedure for starting to receive multicast 

In order to start receiving multicast media stream, the UE is required to join a multicast group. 

The UE shall send a Membership Report Message (IGMP) or Multicast Listener Report Message (MLD) for joining in 
a multicast group. 

The message shall be populated as follows: 

• Multicast Address field is set to the multicast address to be joined in; 

• Source Address field is set to the source address to include if such information is available to the UE and if the 
protocol version allows it. 

7.1 .1 .2 Procedure for stopping to receive multicast 

In order to stop receiving multicast media stream, the UE is required to leave the multicast group. 

The UE shall send a Membership Report Message (IGMP) or Multicast Listener Report Message (MLD) for leaving a 
multicast group, if the multicast protocol version allows it. 

The message shall be populated as follows: 

• Multicast Address field is set to the multicast address to be left; 

• Source Address field is set to the source address to exclude if source address had been included during the join 
procedure. 

7.1 .1 .3 Procedure for channel switching 

In order to operate channel switching, the UE is required to leave the old multicast group and join a new multicast 
group. 

The UE shall send a Membership Report Message (IGMP) or Multicast Listener Report Message (MLD) for leaving 
and joining in a multicast group. 

The message shall be populated as explained in clauses 8.1.1 and 8.1.2. 

7.1 .2 Procedure for BTV with trick modes service 

The IGMP protocol shall be used conforming to [5], clause 7.3.1 for: 

• initiating the BTV with trick mode service on the discovered multicast address; 

• switching from unicast mode back to multicast delivery modes during trick mode operations as defined in [4]; 

• leaving the BTV with trick mode service. 
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7.2 Transport Functions 



For IPv4 multicast IPTV service distribution, the network transport functions shall support minimally IGMPv2 or 
higher. The use of IGMPv3 is recommended, in which case the backwards compatibility rules of [20] clause 7 shall 
apply. 

For IPv6 multicast IPTV service distribution, the network transport functions shall support minimally MLDvl or 
higher. The use of MLDv2 is recommended, in which case the backwards compatibility rules of [21] clause 8 shall 
apply. 



8 Procedures using SIP for dedicated -IPTV 

8.1 User Equipment (UE) 
8.1.1 Procedure for Notifications 

SIP is optional on Tr interface between UE and CFIA or NGN Applications. SIP usage should comply with [25]. 

SIP enabled converged IPTV UE may receive notifications through interactions with the Common NGN ASF as 
defined in TS 182 028 [4], clause A. 

The SIP message body may be used as a generic unified notification container when Common NGN ASF terminates 
notifications from multiples incoming sources, i.e. IMS-IM (SIP), MMS/SMS (MM7, SMPP), e-mail (SMTP), other for 
delivery to the UE via single mechanism. The SIP message body may optionally contain actions, which user are 
allowed to perform. The user can select action(s), which will be passed back to the Common NGN ASF for processing 
as described in clause A.9. 

This procedure shall comply with mechanism described in [18] SIP SUBSCRIBE and SIP NOTIFY. 



8.1.2 Procedure for IVIessaging 



If the UE supports SIP protocol, then alternatively text messages may be delivered via SIP MESSAGE format as 
defined in [10]. SIP message body may be used as a generic unified message container. Common NGN ASF terminates 
messages from multiples incoming sources, i.e. IMS-IM (SIP), MMS/SMS (MM7, SMPP), e-mail (SMTP), other for 
delivery to the UE via single mechanism. The SIP MESSAGE body may optionally contain actions, which users are 
allowed to perform. The user can select action(s), which will be passed back to the Common NGN ASF for processing 
as described in clause A.5. 



9 Procedures using DVBSTP for dedicated-IPTV 

The DVBSTP may be supported by UE and SD&S functional entity. 

9.1 User Equipment (UE) 

9.1 .1 Service Discovery and Selection (SD&S) 

9.1 .1 .1 Request of DVB Service Discovery and Selection data 

In the DVB push model of multicast delivery of DVB SD&S data, the UE shall attach to the multicast DVBSTP 
identified conforming to TS 102 034 [5], clause 5.2. 
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9.1 .1 .2 Request of DVB Broadband Content Guide 

In the DVB push model of multicast dehvery of a DVB BCG data, the UE shall attach to the multicast DVBSTP 
streams identified conforming to TS 102 034 [5], clause 5.2. 

9.2 Service Discovery and Selection (SD&S) 
9.2.1 Procedure for Service Selection 

9.2.1 .1 Delivery of DVB Service Discovery and Selection data 

In the DVB push model of multicast delivery of DVB SD&S data, the DVBSTP protocol shall be used conforming to 
TS 102 034 [5], clause 5.4.1. 

TS 184 009 [26], which specifies the TV URI as globally unique identifier to identify broadcast television channels may 
be used in the mapping of BC service for DVB Technology as follows. The ServiceName attribute of the 
Textualldentifier of TS 102 034 [5], clause C.3.24, should be populated with the TV URI identifying the television 
channel [26]". 

9.2.1 .2 Delivery of DVB Broadband Content Guide 

In the DVB push model of multicast delivery of a DVB BCG data, the DVBSTP protocol shall be used conforming to 
TS 102 539 [8], clause 4.1.2.2.1. 

10 Procedures using RTP/RTCP and UDP for dedicated 
IPTV 

10.1 User Equipment (UE) 

10.1.1 Procedures for Real-Time Transport 

10.1.1.1 Transport using MPEG2TS 

The UE shall be able to receive the content encapsulated into MPEG2TS over RTP conforming to 
TS 102 034 [5], clause 7.1.1. 

The UE shall be able to receive the content encapsulated into MPEG2TS over UDP conforming to 

TS 102 034 [5], clause 7. 1.2. 

If VBR is used, the VBR shall be capped and resource reservation performed at the cap rate. In this case fixed length 
GOP is recommended. 

1 0.1 .2 Procedure for Real-Time Transport Error Correction 

The UE may support a transport error correction mechanism. 

1 0.1 .2.1 Unidirectional Transport Error Correction 

When unidirectional transport error correction is used, the UE shall be able to receive an Application Layer FEC, 
conforming to TS 102 034 [5], annex E. 

If VBR is used, the VBR shall be capped and resource reservation performed at the cap rate. In this case fixed length 
GOP is recommended. 
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1 0.2 Media Delivery Function (MDF) 

1 0.2.1 Procedures for Real-Time Transport 
1 0.2.1 .1 Transport using MPEG2TS 

The MDF shall be able to send the content encapsulated into MPEG2-TS. The MDF shall support: 

• the transport of the IPTV content within MPEG2TS layer over RTF shall be done conforming to 
TS 102 034 [5], clause 7.1.1; 

• the transport of the IPTV content within MPEG2TS layer over UDP shall be done conforming to 
TS 102 034 [5], clause 7.1.2. 

1 0.2.2 Procedure for Real-Time Transport Error Correction 

The MDF may support a transport error correction mechanism. 

10.2.2.1 Unidirectional Transport Error Correction 

For unidirectional transport error correction the MDF shall use an application Layer FEC mechanism, conforming to 
TS 102 034 [5], annex E. 
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Annex A (informative): 

Functional entity relations and example signalling flows of 

NGN based dedicated IPTV operations 

A.1 Functional entities relations and overview of the NGN 
based dedicated IPTV procedures 



Legenda:NGN dedicated IPTV model 

UDP/RTP/RTCP 
Diameter 

RTSP 

HTTP 

IGMP/MLD 

DVBSTP 
Not defined 




NOTE: The above figure represents high level relationships and protocols between the functional entities. The 
detailed procedures and signalling flows are presented in the following sections of this clause. 

Figure A.1 : NGN dedicated IPTV - protocol model with FE relation 

0) Initially, the UE is required to start or boot (i.e. a set-top-box, PC, mobile or any device with an IPTV client) 
and perform network attachment to obtain network parameters (i.e. an IP address, P-CSCF address, etc.). 

1) After network attachment the UE is required to start service initiation steps. 

2) UE performs service provider discovery in order to enable SD&S procedure followed by IPTV service 
selection and attachment as defined in [4]. SD&S can use HTTP over Tr as describe in clause 6 or DVBSTP 
over Tr as described in clause 9. 

3) Then UE performs the service selection procedures with CFIA via Tr (using HTTP over Tr as describe in 
clause 6 to receive service selection information. 

4) At this stage the IPTV UE needs to acquire and use collected service selection information to establish 
appropriate selected service via CFIA 5). 
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NOTE 1 : The IPTV-C is able to initiate resource reservation process for network resources needed by the IPTV 

service according to the capabiHties of the UE. The resource reservation and allocation is performed using 
standardized transport control functions of NGN RACS available to the IPTV-C. 

5) Following the successful session initiation, the IPTV-C informs the MCE via Sa interface (or UE in some 
cases, i.e. BC) about identification of selected content from the Media Delivery Function (or ECF/EFF for BC 
services) to initiate delivery of the selected multimedia content (CoD, nPVR). 

6) The UE may interactively control CoD media stream over the Xc interface (between the UE and the MCE) via 
RTSP protocol (as defined in clause 6). The UE may control BC media stream over the Di interface (between 
the UE and the ECF/EFE) with IGMP/MLD protocol (as defined in clause 7). 

7) The MDF performs media delivery over the Xd interface is based on UDP/RTP stream delivery and several 
transport variants (as described in clause A.2). 

NOTE 2: East Channel Change is being discussed by DVB-IPI for the next release. 



A.2 Example signalling flows of service discovery and 
selection 

SD&S mechanisms used for service discovery, selection and the delivery of service discovery information is based 
upon [5], clause 5.2. 

Service discovery enables the discovery of IPTV services available over NGN dedicated IPTV subsystem. The service 
discovery results in the presentation of services with sufficient information for the user to make a choice and access the 
chosen service. Selection takes place after the user has made a service discovery. 





2. Service discovery 
information 



3. HTTP GET 



4. Service selection 

information (HTTP or 

DVBSTP) 



5. Service initiation (service selection) 



Figure A.2: Service discovery and selection procedures 

1) The UE request service discovery information based on [5], clause 5.2. The request may contain other header 
fields conforming to [9]. 

2) The SD&S response with appropriate XML based answer to UE request with service delivery information. The 
response to the HTTP requests above returns the appropriate XML records defined in [5], clause 5.2.6. 

3) In the pull model of unicast delivery of DVB SD&S data, the HTTP protocol is used conforming to [5], 
clause 5.4.2.2. 
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NOTE: In case of push mode this step is not required. 

4) There are two mechanisms defined, one for muhicast and one for unicast. The protocol DVB SD&S Transport 
Protocol (DVBSTP), clause 5.4.1 [5] is used. The protocol HTTP [9] is used to transport BCG [8] information 
over unicast. 



A.3 Signalling flow and protocol RTP/RTCP for 
Retransmission 

Protocol using RTP/RTCP for Retransmission (Retr)Retransmission solution is optional. Procedure may rely on the 
RTP retransmission solution as specified in [23] and [24], for guaranteeing the delivery of the unicast VoD service and 
broadcast TV services. 

NOTE: RTP/RTCP could be applicable for Fast Channel Change. This work is being discussed by DVB-IPI for 
the next release. 

This clause describes an example of signalling flow for Retransmission. 





1. RTP/U DP content 



MDF 
Retr 



Media 
Management 



I 



Service Configuration 



Retain Content for Retr 



X 



Packet Loss 



2. RTCP FB 



3. RTP witin loj t packet 



Figure A.3: Retransmission signalling 

A.3.1 User Equipment (UE) procedure for BTV service 

For BTV service delivered over RTP/UDP, retransmission service functionality may be signalled towards the UEs. The 
way this is signalled as well as which are the retransmission service configuration parameters is for further study. 

When the UE notices that packet loss may have taken place (based on e.g. RTP sequence number gap detection), it may 
decide to request retransmission of the missing packet(s). This is done by issuing a unicast RTCP Feedback message to 
a feedback target. The RTCP Feedback message has the format of the generic NACK as defined in RFC 4585 [23]. The 
destination port and address of the feedback target is configured at the UE. Upon packet loss detection, the UE may 
wait some time delta T before issuing a retransmission request. This is to allow the feedback target (see further) to send 
a RTCP FB message. If such a FB RTCP message is received from the FB target indicating packet loss corresponding 
with the packet loss detection by the UE, the UE should not issue an RTCP FB message itself. 

The RTCP FB messages do not have to be sent in compound RTCP messages by the UE (i.e. they can be sent 
stand-alone without SDES or RR). The feedback target for the RTCP FB messages can be different from the compound 
RTCP messages (carrying SDES and RR), and the compound RTCP messaging may be even suppressed upon 
configuration. 
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The feedback target also hosts the retransmission server from which the UE should expect the retransmissions. The 
packets that are retransmitted are formatted according to the [24]. The retransmissions can be sent either in unicast or in 
multicast. When the packets are retransmitted in multicast, they have the same multicast group address of the original 
MC RTP stream, but a SSRC identifier is used different from the one in the original stream. When the packets are sent 
in unicast, the SSRC identifier can be identical to the SSRC of the MC stream carrying the original RTP packets. 

The UE supports reception of RTCP messages sent by the feedback target over MC with the same MC group address as 
the MC stream carrying the original RTP packets. These RTCP messages can be RR, SDES, FB messages [23]. As 
described above, a FB message sent out by the Feedback target towards the UE is used for packet loss signalling in 
order to have the UE abstaining from FB messages itself for the signalled packet loss. 

The FB target may also send out Receiver Summary Information (RSI) RTCP messages. RSI messages are formatted 
according RTCPSSM draft (reference) and allow to signal e.g. maximum (upstream) RTCP bandwidth that can be 
consumed by the UE. 

The UE can issue multiple retransmission requests to take into account loss of retransmission packets or retransmission 
requests (RTCP FB message), based on e.g. a time-out mechanism. The maximum number of retransmission requests 
associated with the same packet loss event that can be issued by the UE is application specific. 

The way this is signalled as well as which are the retransmission service configuration parameters is for further study. 

The candidate configuration parameters are: 

• common IP address of the Feedback Target and Retransmission Server; 

• destination Port number of RTCP upstream messages. Destination Port number of unicast RTP 
retransmissions. 

NOTE 1: The above given parameters may be different for each corresponding MC original stream.Optional: 
separate IP address and port for compound RTCP messaging (RR and SDES). 

• Payload type number of RTP retransmission packets. 

• Delta T = Minimum waiting time between packet loss event detection and sending out RTCP FB message by 
UE (to allow reception of RTCP FB messages from Feedback target, which cancel the outstanding UE RTCP 
FB message). 

• Upstream RTCP bandwidth that can be consumed by the UE. 

• The time a packet is available for retransmission. 

NOTE 2: If DVB-IPI is extended to include configuration parameters they should be applicable. 

A.3.2 User Equipment (UE) procedure for CoD service 

For CoD service delivered over RTP/UDP, retransmission service functionality may be signalled towards the UEs. 
RFC 4585 [23] and and RFC 4588 [24] define how retransmissions is supported: 

When the UE notices that packet loss may have taken place (based on e.g. RTP sequence number gap detection), it may 
decide to request retransmission of the missing packet(s). This is done by issuing a unicast RTCP Feedback message to 
a FB target which may coincide with the CoD server. The RTCP Feedback message has the format of the generic 
NACK as defined in RFC 4585 [23]. The destination port and address of the feedback target (when different from the 
CoD server) is configured at the UE. 

The RTCP FB messages do not have to be sent in compound RTCP messages by the UE (i.e. they can be sent 
stand-alone without SDES or RR). 

NOTE 1 : Compound RTCP messages (carrying SDES and RR) may be even suppressed upon configuration. If 
used they are sent to the CoD server. 

The feedback target also hosts the retransmission server from which the UE should expect the retransmissions. The 
packets that are retransmitted are formatted according to the RFC 4588 [24]. The SSRC identifier in the unicast 
retransmission packets is different from the SSRC of the original RTP packet stream, and the same session address/port 
is used. 
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The UE can issue multiple retransmission requests to take into account loss of retransmission packets or retransmission 
requests (RTCP FB message), based on e.g. a time-out mechanism. The maximum number of retransmission requests 
associated with the same packet loss event that can be issued by the UE is application specific. 

The way this is signalled as well as which are the retransmission service configuration parameters is for further study. 

The candidate configuration parameters are: 

• common IP address of the Feedback Target and Retransmission Server; 

• destination Port number of RTCP upstream messages; 

• payload type number of RTP retransmission packets; 

• upstream RTCP bandwidth that can be consumed by the UE; 

• the time a packet is available for retransmission. 

NOTE 2: If DVB-IPI is extended to include configuration parameters they should be applicable. 



A. 4 Example signalling flows of nPVR 

This clause describes an example of nPVR signalling . nP VR service as typically delivered as CoD service and the CoD 
flows from annex C apply. 
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Figure A.4: nPVR signalling flows 

User selected Asset from the list of Assets available for nPVR from Customer Facing IPTV application. 

1) The UE sends an http request to initiate content capture to the CF IPTV Apps. 

2) The CF IPTV Apps asks IPTV control to record the Asset and create recording schedule. 

3) The IPTVC selected MDF for the recording. 

4) The IPTVC passes the recording schedule to MDF. 
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5) The MDF records the program. 
After the recording has started the program is available as normal CoD asset. Flows defined in annex C are applicable. 

A.5 Example signalling flows of IPTV service for 
messaging 

Common NGN ASF should be used for messaging as discussed in clause 5.1.6. 

In case messages are delivered via CFIA as shown in figure A.5, the role of Common NGN ASF is to terminate and 
process multiple incoming messages (i.e. SIP, MM7, SMTP, other) into generic XML schemas, which are then passed 
to CFIA for presentation to the UE. The responses from the UE via CFIA should be passed back to Common 
NGN ASF, which will route the messages to the appropriate destination. 
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Figure A.5: Messaging between IPTV UEs using IHTTP for messaging 

The detailed description of the protocols and messages flows: 

1) User 1 sends message to the IPTV user 2. 

2) The UEl sends HTTP request with attached message and destination identifier to the CFIA. 

3) The CFIA forwards message to the NGN ASF messaging server. 

4) According to policies the NGN ASF may request IPTV sub-profile of federalized user profile from 

NGN UD AF if this information is not stored in NGN ASF. The NGN ASF identified destination UE based on 
policy and destination information. 

5) If based on policies the message could be forwarded to the IPTV UE2, the Common NGN ASF informs CFIA 
about the incoming message. 

6) The CFIA delivers message to UE 2. 

7-8) Successful delivery is confirmed to UE 1 via CFIA. 

9) The message is presented to user 2. 

NOTE 1 : The message can be directly delivered from and to Common NGN ASF. 
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Figure A.6: Messaging between from SIP capable UEs to IPTV UE 

1) The UEl is a SIP capable device, compliant with [10] or for interaction with IMS core compliant with [11]. 

2) The UEl generates and sends a SIP MESSAGE to the SIP proxy. 

3) The SIP proxy forwards message to NGN ASF. 

4) The NGN ASF checks user profile and policy for incoming messages and based on this information it 
forwards the message to IPTV UE2 network. 

5-6) The Message is delivered and presented or stored in message box of the UE2. 

7-9) The response is replied back to the UEl via Common NGN ASF. 

NOTE 2: The deUvery to the IPTV UE can be both directly from the Common NGN ASF and via the CFIA as 
described in the above flow. 

The flows above are applicable to the delivery of messages from other sources such as IMS-IM (SIP), MMS/SMS 
(MM7, SMPP), e-mail (SMTP), other to IPTV UE via a single notification interfaces utilizing either HTTP or SIP. 

To simplify the message processing, user actions can be packed together with the messages, e.g. to reply to the message 
or to store the received message in the user message box. The user selection can be passed back to the Common ASF 
for processing, i.e. to remove message specific processing from the UE. In this case the following XML schema is 
recommended. 

<?xml version="l . 0" encoding="UTF-8" ?> 

<xs : schema xmlns :xs = "http : //www.w3 . org/2 00 1/XMLSchema" 

xmlns :uep="urn:org: etsi :ngn:params :xml :ns : iptvnotif ication" 

elementFormDefault= "qualified" 

attributeFormDefault=" unqualified" > 

<xs:element name="IPTVNotif ication" type="tIPTVNotif ication"/> 
<xs : complexType name="tIPTVNotif ication" > 
<xs : annotation> 

<xs :documentation>XML Schema for representing Notification identified in TS 182 028 
clause 5 . 1 .X</xs :documentation> 
</xs : annotation> 
<xs : sequence> 

<xs:element name="Action" type="tIPTVNotif icationAction" minOccurs="l" 
maxOccur s = " unbounded " / > 

<xs : element name="Notif icationDescription" type="tIPTVNotif icationDescription" 
minOccurs= " 1 " maxOccurs= " 1 " / > 
</xs : sequence> 
</xs : complexType> 
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<xs relement name="tIPTVNotif icationAction" type="tIPTVNotif icationAction"/> 
<xs : complexType name="tIPTVNotif icationAction" > 
<xs : sequence> 

<xs:element name="ActionType" type="tIPTVNotif icationActionType" minOccurs="l" 
maxOccurs= " 1 " / > 

<xs : element name="ActionTypeDescription" type="tIPTVNotif icationDescription" 
minOccurs= " 1 " maxOccurs= " 1 " / > 
</xs : sequence> 
</xs : complexType> 

<xs : simpleType name="tIPTVNotif icationActionType" final="list restriction" > 
<xs : restriction base="xs : string" > 
<xs iminLength value="0"/> 
<xs imaxLength value="16"/> 
</xs : restriction> 
</xs : simpleType> 

<xs : simpleType name="tIPTVNotif icationDescription" final="list restriction" > 
<xs : restriction base="xs : string" > 
<xs iminLength value="0"/> 
<xs :maxLength value="128"/> 
</xs : restriction> 
</xs : simpleType> 

</xs : schema> 



A. 6 Example signalling flows of IPTV presence services 

A. 6.1 Example signalling flows of IPTV presence notification 
using PA 
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Figure A.7: Presence services to IPTV UE using PA 
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1) The UEl may subscribe to presence service information and use HTTP POST to request the information via 
CFIA. 

2) The CFIA forwards the request to NGN ASF to check the user profile. 

3) The NGN ASF may check profile and perform authorization for usage of presence service within the IPTV. 

NOTE 1: Authorization regarding the submission of presence information from the presence service may use [15] 
with authorization rules content [16] independently. The exact procedure is outside the scope of the 
present document. For the current flows it is assumed that UE2 authorized access to the presence. 

4) The NGN ASF subscribes to the presence information on behalf of the user. 

5) The subscription is confirmed to the NGN ASF. 

6) After the initial subscription PS sends initial presence status via SIP NOTIFY (actual presence if any 
available). 

7) The notification is confirmed to the PS. 

8) The presence state changes or is published for first time. 

9) The PS informs the NGN ASF about presence state change using SIP NOTIFY. 

10) Notification is confirmed to the PS. 

11) The NGN ASF generates http 200 OK with attached presence information in XML document. 

12) The presence information is forwarded to the UEl 

NOTE 2: For steps 1 1 and 12 HTTP POST may be alternatively used to deliver presence information to the UE. 

13) The UEl displays information or updates presence status on user interface. 

The Presence User Agent in the Common NGN ASF may report presence directly to the converged IPTV UE in step 1 1 . 

The Presence User Agent may perform presence status collection and reporting from NGN IPTV to NGN Presence 
Server. 
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A. 6. 2 Example signalling flows of IPTV presence notification 
using RLS 
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Figure A.8: Presence services to IPTV UE using RLS 

1) The UEl may subscribe to presence service information and use HTTP POST to request the information via 
CFIA. 

2) The CFIA forwards the request to NGN ASF to check the user profile. 

3) The NGN ASF may check profile and perform authorization for usage of presence service within the IPTV. 

NOTE 1: Authorization regarding the submission of presence information from the presence service may use [15] 
with authorization rules content [16] independently. The exact procedure is outside the scope of the 
present document. For the current flows it is assumed that UE2 authorized access to the presence. 

4) The NGN ASF subscribes to the presence information on behalf of the user. The request is sent to a Resource 
List Server as described in [14]. 

5) The RLS subscribes on behalf of the user also to presence information of all users, In this particular case, the 
user supplying presence is the UE2. 

6) The subscription is confirmed to NGN ASF. 

7) After the initial subscription the PS sends presence via SIP NOTIFY (if any is available). 

8) The UE2 informs the RLS about changes in the presence state via SIP NOTIFY 

9) The RLS sends resource-list notification as described in the [14]. 

10) The notification is confirmed via SIP 200 OK. 

1 1) The NGN ASF generates http 200 OK with attached presence information in XML document. 

12) The presence information is forwarded to the UEl. 
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NOTE 2: For steps 1 1 and 12 HTTP POST may be alternatively used to deliver presence information to the UE. 

13) The UEl displays information or updates presence status on user interface. 

The Presence User Agent in the Common NGN ASF may report presence directly to the converged IFTV UE in step 1 1 . 

The Presence User Agent may perform presence status collection and reporting from NGN IPTV to NGN Presence 
Server. 

A. 6. 3 Example signalling flows of IPTV presence updates 
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Figure A.9: Presence information about IPTV services used by UE1 

The IPTV UEl may inform IPTV application server about state of services used by the UEl. 

1) When new event occurs or IPTV application server makes an update request, the UEl may send related 
presence information in XML format. 

2) The UEl generates and sends XML presence state to the CFIA. 

3) The information is processed and forwarded to the to the presence agent in the Common NGN ASF. 

NOTE: Structure of XML document may follow XML schema defined in [17], annex E: "XML schema for IPTV 
presence document extension". 

4) The presence information is updated. 

5-6) The presence update is confirmed to the UEl via HTTP 200 OK. 

Alternatively, the Presence User Agent or Presence Network Agent may perform presence collection and reporting from 
NGN IPTV to NGN Presence Server. 

A. 7 Example signalling flows of IPTV service interaction 
with NGN/IMS services 

This clause provides description about interaction procedures between IPTV and other NGN/IMS service level 
subsystems, e.g. IMS, for composite services. In the data flows it is assumed that both IMS users (IMS UE) are 
registered in IMS subsystem. The procedure describes several types of the interactive features in converged NGN IPTV 
applications (e.g. presenting a caller ID of an incoming call on the TV screen). 



£75/ 



36 



ETSI TS 183 064 V2.1.1 (2008-10) 



A. 7.1 Example signalling flows of IPTV service handling of 
incoming calls 

In this scenario User 1 calls towards User 2 and both have their IMS UEs in IMS domain. User 2 is subscribed to a 
converged IPTV service (e.g. caller ID notification with options to accept, forward or reject incoming call when his 
IPTV service is active) via the IPTV UE (which have service mapping/relationship with IMS UE 2). 

There may be supported at least 3 cases for incoming call handling: 

• confirm acceptance of incoming call; 

• refuse call; 

• forward call to voice mail or other terminal. 
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Figure A.10: High level interactions procedure between IPTV and 
other service level subsystems - NGN/IMS inter-working with NGN dedicated IPTV 

NGN ASF should be used for mapping SIP messages to generic XML schemas which should be processed by 

IPTV ASF that will present information to IPTV UE (and receive/forward user reaction, e.g. confirmation for receiving 

call back to core IMS) related to user IMS UE. 

The detailed description of the used protocols and messages is following: 

1) A usual SIP INVITE message with information about destination user, call originating user, type of call, 
optionally further parameters is forwarded from NGN (core IMS). 

2) S-CSCF access user profile data. Dotted line indicates that IMS user profile has been requested from UPSF 
(at regular IMS registration). 
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3) Based on IMS user profile the SIP INVITE is forwarded by the S-CSCF to the NGN ASF via ISC interface. 
NGN ASF acts for the S-CSCF as an IMS AS that can receive SIP messages. A mapping between the SIP 
identifiers from SIP INVITE message and corresponding IPTV UE device ID (of User 2) can be required. 
The mapping identifiers may be performed within NGN ASF using information about user stored locally or 
e.g. in the NGN UDAF (but detail process or place of storage for this information is out of scope for the 
present document). 

NOTE 1: In case that user 1 sends messaging/notification information via SIP MESSAGE to user 2 same mapping 
of SIP identifiers could be applied for delivery information ant their transformation to presentable format 
to IPTV UE of user 2. 

4) According to policies the NGN ASF may request IPTV sub-profile of federalized user profile from NGN 
UDAF if this information is not stored in NGN ASF. 

5-6) Optionally the request can be also forwarded to lUDF. The exact specification of this is out of scope for the 
present document. 

7) When required user data and service information are delivered and available for the NGN ASF. Further steps 
are performed if user has subscription for such converged service activated and IPTV UE is online. 

8) A mapping from SIP messages to the XML message is performed by the NGN ASF. The XML notification 
message is used for that delivery and presentation service information to IPTV UE (directly or via Client 
Facing IPTV application - step 9). 

The mapping of relevant information from SIP message to XML have to be generated by NGN ASF 
including required SIP identifiers and service information (e.g. call line ID transferred in the XML 
notification message) in form presentable by IPTV ASF (Client Facing IPTV Application) or finally to the 
IPTV UE. Mapping is following: 

SIP identifiers of destination URI mapped to IPTV UE ID of User 2 (the mapping has been already 
performed); 

SIP identifier of originating URI with information about User 1 (information who is calling or sending 
message); 

SDP parameters - optionally service information and parameters about the call like subject, type of call 
(emergency, priority), etc. 

9) The service information can be then presented to IPTV UE from IPTV ASF (via Tr and using HTTP). 

10-12) The IPTV ASF may require future action from User 2 on IPTV UE whether user has for example accepted 

the call or rejected. This response messages are returned back to NGN ASF which will react appropriate way 
back towards IMS (e.g. forwarding back SIP INVITE to IMS UE of User 2). 

NOTE 2: Similar mechanisms may be used also for interaction with other services such as presence or messaging. 

NOTE 3: Similar procedure should be used for IPTV interaction with SIP based architecture based on 
RFC 3261 [25] (in this case SIP proxy is used instead of S-CSCF). 
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A. 8 Example signalling flows of Notifications 

Common NGN ASF may be used for notification services to the IPTV UE as described below, i.e. for emergency 
alerting, advertising or maintenance notification. 
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Figure A.11 : Notification services to IPTV UE 

The description of the protocols and messages illustrated below. 

1) The User 1 subscribes to the Notification service. 

2) The NGN ASF confirms successful subscription by 200 OK. 

NOTE 1 : Step 1 and 2 may be performed via CFIA, in this case the steps may be directly between NGN ASF and 

UEl. 

3) The notification event occurs and the NGN ASF performs action to inform the User 1 . 

4) The NGN ASF may request IPTV sub-profile of federalized user profile from NGN UDAF and policies. The 
NGN ASF may decide, i.e. based upon received profile or policies, the right UE to send the notification to. In 
this case the IPTV UEl is selected, but different UE, i.e. SIP based, may be used. 

5) The NGN ASF informs the CFIA about notification event which should be presented to UE. 

6) The IPTV ASF confirms receiving information with notification data in XML format (e.g. the UE identifier, 
notification message, etc.). 

NOTE 2: Steps 5 and 6 are not required when direct notification to the UE is used, i.e. SIP based. 

7) The notification message is delivered to the UE 1 (via HTTP and Tr interface). 

8) The deUvery is confirmed to the NGN ASF. 

NOTE 3: Steps 7 and 8 may be performed via CFIA or directly between the NGN ASF and UEl. 

9) The notification information is present to the user or stored in the UE message box. 
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NOTE 4: Notification methods should use HTTP over Tr interface. Optionally for SIP enabled UE, the SIP 
notification should comply with [18]. 

User actions can be delivered together with the notification and user selection passed back to the Common ASF for 
processing, i.e. to simplify message processing on the UE and remove specific message processing logic from the UE. 
In this case XML schema defined in clause A.5 is recommended. 
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Annex B (normative): 

UE capabilities and example signalling flows of NGN based 

dedicated IPTV operations 

B.1 UE capabilities 

UE supports following specifications: 

• HTTP: 

HTTP protocol shall be used conforming to [5] and follow standard HTTP [9]; 

HTTP Digest [7] is recommended on the Tr interface; 

MD5 is recommended digest algorithm as defined in [19], MD5 Message Digest Algorithm; 

UE should implement an http compliant web browser with JavaScript support; 

• RTSP: 

Support of RTSP methods in NGN dedicated IPTV as described in clause 6 (based on RTSP usage 
in [5]); 

Optionally HTTP Digest Access Authentication can be applied to RTSP control messages as defined 
in [19]; 

• IGMP/MLD: 

If IPv4 is used for the transport, the UE shall support IGMPv3 as described in [20] ; 
If IPv6 is used for the transport, the UE shall support MLDv2 as described in [21]; 

• Transport and encapsulation based on [5]: 

The UE shall be able to receive the content encapsulated into MPEG2TS over RTP conforming [5], 
clause 7.1.1 and MPEG2TS over UDP conforming [5], clause 7.1.2; 

• DVBSTP: 

If DVBSTP for multicast (which is optional for UE) is used then it shall conform to [5], clause 5.2; 

• SIP: 

For SIP capable UE interactions with messaging services, SIP MESSAGE should used conforming to 
[10]; 

For SIP capable UE interactions with notification services, SIP SUBSCRIBE and SIP NOTIFY should 
be used conforming to [18]. 
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B.2 Signalling flows of BTV 

This clause describes an example of signalling flow of session initiation and termination for BTV. 



UE 



ECF/EFF 



X 



SD&S 

And 

CF IPTV 

Apps 



I 



Content Selection: Multicast Address 



1. Multicast R 



Session Initiation 



iport (Join) 



2. Resource Reservation & 
Admission Control 



Media Stream 



1 . Multicast R sport (Leave) 



Session Termination 



2. Resource Release 



Figure B.I : Signalling flows for BTV operation 

ECF/EFF is typically a part of the Access Network as shown on TS 182 028 [4], figure 4. 

User selected BTV channel during SD&S process. UE has received multicast address to join. 

To start the service: 

1) The UE sends a multicast Join request (Membership Report Message (IGMP) or Multicast Listener Report 
Message (MLD) ) to start receiving multicast media stream. The UE populates the message as follows: 

multicast Address field is set to the multicast address to be joined; 

if the protocol is IGMPv3 or MLDv2: 

■ if source addresses have been advertised, the Record Type is set to "ALLOW_NEW_SOURCES" 
ECF/EEFd Source list is set to the source addresses; 

■ if no source address has been advertised, the Filter mode is set to "EXCLUDE" and Source list is 
set to "empty". 



2) Local resource reservation and admission controlled is performed by the ECF/EEF as defined in [3]. 
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Media stream is delivered. 
To leave the service: 

1) The UE sends a multicast Leave request (Membership Report Message (IGMP) or Multicast Listener Report 
Message (MLD) ) to stop receiving multicast media stream. The UE populates the message as follows: 

multicast Address field is set to the multicast address to be left; 

if the protocol is IGMPv3 or MLDv2: 

■ if source addresses have been set in the Join message, the same source address list is excluded from 
the listening interface; the Record Type is set to "BLOCK_OLD_SOURCES" and Source list is set 
to the source address; 

■ if no source address has been set in the Join message, Filter Change record is set to INCLUDE with 
an empty source list. 

2) Local resource release is performed by the ECF/EEF as defined in [3]. 
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B.3 Signalling flows of CoD 

This clause describes an example of signalling flow of CoD session initiation and termination. 



B.3.1 CoD Session initiation 
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Figure B.2: CoD session initiation 

User selected CoD asset during SD&S process. UE has received asset URL. 

1) The UE sends RTSP SETUP to the IPTV control with the asset URL. 

2) The IPTVC control selects MCF. 

3) The IPTVC control reserves resources between MDF and UE. 

4) The IPTVC control returns selected MCF in the REDIRECT message. 

5) TCP connection for RTSP is established between UE and MCF. 

NOTE 1 : Optionally RTSP method DESCRIBE may be used before SETUP to request media delivery initialization 
information from MCF if the parameters have not been sent by IPTV control within REDIRECT 
sequence (1 to 5). 
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6) The UE sends RTSP SETUP to the IPTV control with the asset URL. 

7) The CoD-MF sends 200 OK with SDP. The SDP contains the session descriptions of UDP/RTP stream to be 
used. 

8) Optionally, the UE extracts the media descriptions from the SDP of 200 OK. 

9) The UE sends RTSP PLAY command. 

10) The CoD-MF starts sending UDP/RTP content streams to the UE. 

NOTE 2: If coupled mode is used for CoD procedure the steps 1 to 4 are not needed (procedure start from step 5). 

NOTE 3: After successful authorization of the service request, the key exchange and delivery of security metadata 
to the UE may be initiated in accordance with the media content protection model as described in 
TS 187 003[i.l]. 

B.3.2 CoD Session termination 




1. RTSP TEAR DOWN (optional Re sources_Conf_ID 



2. UDP Content Stream is terminated 



3. Resource Release 
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Figure B.3: CoD session initiation 

1 ) TEARDOWN request is sent to CoD-MF. 

2) CoD-MF stops sending UDP/RTP content streams. 

3) The CoD MF requires for RACS to release resources. 

4) The CoD MF responds with 200 OK response. 



B.4 Signalling flows of BTV with trick modes 

This clause describes an example of signalling flow of BTV session initiation and termination. BTV with trick modes is 
a superimposition of BTV and CoD sessions in a single service as discussed in [4]. 

The switch from BTV to trick modes is shown in figure B.4. 

ECF/EFF is typically a part of the Access Network as shown on TS 182 028 [4], figure 4. 
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Figure B.4: BTV with trick modes: switch to tricl< modes 

User is watching BTV channel and wants to initiate trick mode. 

1) The UE sends a multicast leave request (Membership Report Message (IGMP) or Multicast Listener Report 
Message (MLD) ) to stop receiving multicast media stream. 

NOTE: Local resource reservation and admission controlled is performed by the ECF/EFF as defined in [3]. 

2) The UE sends RTSP SETUP to the IPTV control with the asset URL. 

3) The IPTVC control selects MCF. 

4) The IPTVC control reserves resources between MDF and UE. 

5) The IPTVC control returns selected MCF in the REDIRECT message. 

6) TCP connection for RTSP is established between UE and MCF. 

7) The UE sends RTSP SETUP to the IPTV control with the asset URL. 

8) The CoD-MF sends 200 OK. 

9) The UE sends RTSP PLAY command. 

10) The CoD-MF starts sending UDP/RTP content streams to the UE. 
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